Communications devices are used throughout most of the world and are often designed and developed to operate with at least one, if not more than one, communications network. Each communications device is uniquely identified within a network and is often uniquely identified within the network, thereby enabling a communications source device to contact the receiving device through connection points across the network. Similarly, each communications device is tracked on a network for its use of bandwidth in operation on one or more networks.
These communications devices are often in the form of a cellular-based devices, (e.g., phones, smartphones, etc.), sensor-based devices (watering systems, parking meters, alarm indicators, etc.), or other data intensive devices capable of communicating on a network. Still other devices may include one-way communicating equipment, such as medical emergency or alarm-based equipment that contacts a receiving device or system across a network. The use of the term communications device or “device” herein is not intended to be limited to examples set forth, but rather incorporates and includes any device capable of communicating on, with, and/or across a communications network, wired or wireless, and thereby uses network resources of bandwidth to upload, download, transmit, receive, or transceive data. Examples of devices may include: laptops with 3G or WIFI capability; smartphones with 3G, 4G or CDMA/GSM; alarm systems across a publicly switched telephone network (PSTN) line; texting equipment; a machine-to-machine (M2M) environment; and similar.
In many applications, a communications device may not be physically connected with a communications network and may be able to connect with multiple communications networks owned by different entities. Tracking the use of a particular device on various networks is an important activity as the use of a network's bandwidth is typically the primary source of monetization for operators of a network.
FIG. 1 depicts a basic M2M communication network 100 having typical sensor-type devices 120, 130 and 140. Cell phones at 145 and 155 are also provided. In FIG. 1, the M2M network 100 has a central communication gateway 110 in which communications from devices 120, 130, 140, and 145 are linked with a service provider network 150. The linkage may be wired or wireless, and is depicted as the security camera 120 and the water alarm sensor 130 are in wireless communication with the gateway 110. Similarly, the traffic camera sensor 140 is in wired communication with the gateway, though one will appreciate that there are many variations to the type and protocol of communication for FIG. 1. As one can appreciate, there may be many variations and types of devices included for a M2M communication network and communication-capable devices thereon.
From FIG. 1, data sensed and obtained by the devices is transmitted across the M2M network to the service provider network 150 where the data may be shared as raw data or converted to information, often though software applications. Notification equipment 160 wirelessly receives the data from the service provider network 150, as may the cell phone 155, and acts in accordance with the received data for the specific event. For instance where the notification equipment is an alert system to send a text to a building owner in the event of a water leak, and the water sensor has sent data indicating a water leak, the notification equipment will then trigger an event to notify the building owner.
Similarly, from FIG. 1, where the user 170 receives a suite of rolling historical data as to traffic camera operation cycles, the user may then act accordingly based on the received cumulative information. The transmission and receipt of data across the network from varied devices can be tracked on a per device basis, a per grouping of device basis, and across the network. The usage of data by a device is often then billed to a device-owning consumer (or user) based on a consumption rate plan that provides for a certain amount of time and/or use of data by a device owned by the user.
In certain M2M applications, particularly those in the telemetry space, to monitor and control a remote device usually requires a number of components to be present, including: (1) a central processing unit (CPU) to run the remote application and control the radio module associated with the device; (2) non-volatile random access memory (NVRAM) to store the operating system, application code and data; (3) I/O interfaces; and (4) a Radio Module for remote access.
Further to the description above, FIG. 2 sets forth a typical M2M telemetry device design 200 for monitoring and controlling a remote device.
From FIG. 2, components for a typical M2M telemetry device design used for controlling a remote device, such as remote sensor devices, are set forth at 202. Within 202 are included a radio module 205, a CPU 210, a NVRAM 215, a Parallel Identifier (PID) 220, an Analog-to-digital converter (ADC) 225, and a Digital-to-analog converter (DAC) 230. The CPU is generally central to the communication pathways of the components of the controlling device of 202. Remote devices being sensors 240, 250 and 260 are available for communications with the controlling device 202, where control information is passed from the controlling device 202 to the remote sensors to instruct what information or monitoring is sought. Examples of sensors are set forth in FIG. 2 as an external relay 240, an analog sensor 250, and a variable analog control 260, though one will appreciate there may be many variations and types used with the present invention.
However, each of these component requirements for the controlling device, in addition to those involving low-level application code requirements, add cost and complexity to the device and often may create certain product development delays associated with the complexities of the device design. Further, the development of low level application code is often quite complex, time consuming and expensive, and in generally is often a main cause of product development delays for such device designs.
Further to the above, FIG. 3 sets forth a M2M telemetry device design using I/O enabled modules 300.
From FIG. 3, a radio module 305 is in communication with a CPU 310 and NVRAM 315, as well as with remote sensors 340, 350 and 360. The radio module is I/O enabled having input/output communications with the sensors, reducing the need for ADC, DAC and PID to be communication intermediaries with the remote sensors as shown in FIG. 2. A radio module, such as that of 305, may provide direct I/O capabilities including: General Purpose Digital I/O (GPIO), ADC, DAC and voltage output controls (VOC), for instance.
Unfortunately, from FIG. 3, even where developers may be able to realize a design advantage, there is often an economic disincentive for this approach as though hardware costs and board design simplification may occur; these capabilities often require expensive components, such as the CPU, NVRAM and the operating system, to be present on the device. For instance, though the radio module is I/O enabled, the presence of additional components such as CPU, NVRAM and operating system is still necessary locally. Also, often a radio module and CPU are underpowered to adequately perform in this environment. Additionally, the development time associated with such an approach may still be very long and difficult. Further, design errors are known to arise, particularly where, in an effort to reduce development costs, the failure to include critical capabilities such as remote firmware updates may occur.
Additionally, web-based uniform resource indicators (URIs) are often used to identify resources associated with a network, such as devices. URIs can include locators (URLs), names (URNs), etc., where typically the URI provides information to define an identity of or method for locating the resource. However, web-based hyper text transfer protocol (HTTP) URIs can often be cumbersome though they may often be convenient for human consumption. These URIs are often lengthy and complex in form and need to be transmitted accurately, in their entirety, for appropriate operations.
For example, a URI may take the form of: “/1751234567/GPIO/1” which is descriptive to a web browser (also used herein as a “fully descriptive URI”). The fully descriptive URI format associates the 1751234567 with a module ID that is globally unique to the radio module; it associates the GPIO with a general purpose I/O type ID for a port, although there may be multiple types of I/O ports present; and it associates the 1 with a port ID that is unique within the I/O port type identified. Often, these details are populated by the radio module manufacturer.
Therefore, what is needed is a cost-effective and lesser-intensive component content approach which will allow monitoring and control of remote devices using a radio module's built-in I/O capabilities, while eliminating the requirement for firmware application development and expensive component requirements to be locally present, such as a CPU or NVRAM, for instance. What is also needed is an improved method of providing a less cumbersome approach of relevant information typically associated with a fully descriptive URI. It is therefore desired to provide such an approach as that above which further enables developers to realize a reduction in hardware costs, an elimination of license fees and a simplified software development process by providing for network control of a radio module.